In 3rd Generation Partnership Projection (3GPP), TS 36.213 (V13.2.0, June 2016) defines Transport Block Size (TBS) to be used by network entities for communications. Referring to Section 7.1.7.2.1 of TS 36.213, for 1≤NPRB≤110, the TBS is given by the (ITBS, NPRB) entry of Table 7.1.7.2.1-1 (partly truncated as Table 1 below). Herein, ITBS denotes TBS index determined by Modulation and Coding Scheme (MCS), and NPRB denotes total number of allocated Physical Resource Blocks (PRBs).
This is a basic L1 (Layer 1) parameter for Media Access Control (MAC) operation. Specifically, MAC provides the dynamic transport block size from a table as this one to Radio Link Control (RLC) sublayer, the RLC may accordingly build its RLC Packet Data Unit (PDU), and during this PDU construction, some Service Data Unit (SDU) segmentation and concatenation are done.
In general, Table 1 holds a TBS candidate listing for MAC operation. A plurality of such tables are made available at 3GPP standards for different spatial layers and Downlink Control Information (DCI) formats.
Also, in 3GPP TS 36.213, several TBS translation tables (one-layer to two-layer, three layer and four-layer) are also provided (cf. Table 7.1.7.2.2-1, Table 7.1.7.2.4-1, Table 7.1.7.2.5-1 in TS 36.213).
TABLE 1Transport block size table (dimension 34 × 110)(Table 7.1.7.2.1-1 in TS 36.213)NPRBITBS123456789100163256881201521762082242561245688144176208224256328344232721441762082562963283764243401041762082563283924405045684561202082563284084885526326965721442243284245046006807768726328176256392504600712808936103271042243284725847128409681096122481202563925366808089681096125613849136296456616776936109612561416154410144328504680872103212241384154417361117637658477610001192138416081800202412208440680904112813521608180020242280132244887441000125615441800202422802536142565528401128141617361992228026002856152806009041224154418002152247227283112163286329681288160819282280260029843240173366961064141618002152253628563240362418376776116015441992234427923112362440081940884012881736215226002984349638804264204409041384186423442792324037524136458421488100014801992247229843496400845844968225201064160821522664324037524264477653522355211281736228028563496400845845160573624584119218002408298436244264496855445992256161256186425363112375243925160573662002671214802216298437524392516059926712748026A 632128819282600324038804584516059926456. . .NPRBITBS101102103104105106107108109110276659266592688086880868808711127111271112711127371228711127111273712737127371275376753767620876208762082975376762087620876208787047870478704811768117681176307870481176811768117681176847608476084760847608793631847608476084760847608793687936879368793690816908163287936879368793687936908169081690816938009380093800339789697896978969789697896978969789697896978969789633A87936879368793690816908169081693800938009380097896
URLLC means Ultra-Reliable and Low-Latency Communications, which was one of cases defined in 3GPP TR 22.862 (V14.0.0, June 2016). In this category, both reliability of communication and low latency are highly demanded. It can be noted that these requirements are mutually conflicting in some aspects as usually these two aspects are traded for each other. In general, it is relatively easy to achieve one aspect by trading-off the other, while for URLLC both should be met at the same time, which pose a remarkable challenge to User-Plane (UP) design. According to 3GPP TR 22.862, the latency requirements for URLLC ranges from 1 ms to 10 ms for different concrete applications ranging from automation applications, smart grid to intelligent transportation, and reliability from a residual error rate of 104, 10−6, to 10−9. The packets in URLLC scenarios are of quite small size such as 50 to 100 bytes per packet. It is noted that such residual error rate calculation will also consider those packet later than the demanded latency bound such as 1 ms or 10 ms as errors or invalid in the context of URLLC.
Simultaneously achieving such high demands on both reliability and latency may impact many layers and components of both Radio Access Network (RAN) and Core Network (CN). URLLC can be regarded as an extremely high QoS use case both in RAN and CN.
Additionally, Bandwidth reduced Low complexity (BL) User Equipment (UE) and Coverage Enhancement (CE) UE are specified in 3GPP Standard Release 13. Long Term Evolution (LTE)-M1 transmits Mobile Physical Downlink Control CHannel (MPDCCH), Physical Downlink Shared Channel (PDSCH), Physical Uplink Shared CHannel (PUSCH) in time domain repetition fashion and works only at 1.4 MHz. This type is for Machine Type Communication (MTC) in narrow band.
In URLLC cases, the high reliability and latency requirements make the current TBS table mapping less effective. The LTE-M1 UE type: (BL UE/CE UE) has been specified in release 13, and some reliability boosting by repetition-based transmission was standardized. However, URLLC may have a higher reliability requirement and its short latency requirement makes the time domain redundancy-based diversity less attractive as it may take more time. For instance, the retransmission-based time diversity takes time, it may not be allowed for most latency rigorous URLLC use cases. Besides, dynamic link adaptation takes time to converge. A more robust link gain control mechanism is necessary for URLLC.